Timestamp to human readable date&time string (Martin Poloch home assignment) #1535
Conversation
| first_daily_timestamp = utime.mktime(date) | ||
| # calculate correction of the midnight timestamp to the origiral | ||
| correction = timestamp - first_daily_timestamp |
There was a problem hiding this comment.
The "correction" can be calculated more simply by taking correction = timestamp % 86400.
| returned date (2021, 3, 18, 0, 0, 0, 3, 77, 0) | ||
| correction 31624 (~ 8:47:04) | ||
| """ | ||
| approx_datetime = utime.localtime(timestamp) |
There was a problem hiding this comment.
On the actual device this fails with:
AttributeError: 'module' object has no attribute 'localtime'
There was a problem hiding this comment.
Even if we got this working, I suspect that it might give an incorrect time on the device, because the STM32 implementation seems to be using 2000-01-01 as the beginning of the epoch as opposed to the UNIX implementation which uses 1970-01-01. It's hard to believe, but that's what I see in the C code. I didn't actually test.
There was a problem hiding this comment.
Yes, from my limited sources, I expect the behavior you described. Sorry for not mentioning it in the PR description.
There was a problem hiding this comment.
If the two implementations are really using different epochs, then I have doubts whether we should be using utime at all. We would then have to have a piece of code like "If not EMULATOR, then subtract 30 years", which just seems very wrong.
Secondly, there is #741, which indicates that there may have been some opposition to adding the utime module to the firmware build.
There was a problem hiding this comment.
I just added PR #1548 to update uPy to 1.14 - among other things it introduces utime.gmtime() function which is exactly what we need here I suppose.
There was a problem hiding this comment.
fwiw #741 is not opposed to adding utime, but adding full python's datetime. At that time there was probably no date processing in utime, but now there is.
|
|
||
| def _calculate_timestamp_correction(timestamp: int) -> (Tuple[tuple, int]): | ||
| """ | ||
| utime module can't convert timestamp to datetime with seconds precision. |
There was a problem hiding this comment.
It looks like this problem occurs only in the UNIX implementation, because micropython quite pointlessly converts the timestamp to a C float which has a mantissa of 23 bits, causing the lower bits to get lost. The STM32 implementation reads it as an integer.
There was a problem hiding this comment.
This is actually fixed upstream.
There was a problem hiding this comment.
Yes, we need to merge MicroPython 1.14 in before merging in this PR - #1548
matejcik
added
the
blocked
matejcik
added
core
|
we now have uPy 1.17 so we are able to continue on this apart from Bitcoin lock-time, this should be used in Stellar timebounds |
Code uses utime module which in current version offers only timezone-dependant function to convert timestamp to datetime (utime.localtime). Tested only on core emulator with computer timezone set to UTC.
The mentioned function also looses precision of the conversion with increasing timestamp. The precision is much worse than 1 second around current timestamps and with future timestamps (in more than 100 years), the precision is less than a minute and even less.
Workaround was implemented so the current precision is 1 second for the next few decades but I still suggest further inspection.